Profile picture

[k8s] 쿠버네티스 도커 지원 중단

JaehyoJJAng2023년 03월 05일

▶︎ 개요

쿠버네티스에서 도커의 사용이 중단된다는게 진짜일까요?

왜 중단하게 되었는지 그 과정에 대해서 자세히 알아봅시다.


▶︎ 쿠버네티스와 도커의 관계

쿠버네티스는 초창기에는 도커와 호환이 잘 되는 도구였어요.

하지만 버전이 올라감에 따라 쿠버네티스에서는 도커가 아닌 다른 컨테이너 런타임(CRI)를 도입하고 싶어졌어요.

운영하는 워크로드에 따라 보안에 중점을 둔 런타임, 성능에 중점을 둔 런타임 등 입맛에 맞게 유연하게 쓰고 싶었기 때문이죠.

image
이에 2020년 12월 08일. 쿠버네티스는 여러 컨테이너 런타임과 통신할 수 있도록 CRI라는 표준 인터페이스를 설계하였습니다.


🚨 하지만 여기에는 큰 문제가 있었죠.

Docker는 이러한 CRI 인터페이스가 생기기 이전에 존재한 기술이었기 때문에 CRI 인터페이스와 호환되지 않았어요!

이로 인해, 도커는 더이상 컨테이너 런타임으로써의 사용이 불가능해지는 입지에 놓이게 됩니다.

이에 쿠버네티스 개발진들은 도커를 컨테이너 런타임으로 계속 사용할 수 있도록 dockershim 이라는 어댑터 컴포넌트를 개발하게 됩니다.

이러한 dockershim은 도커와 쿠버네티스의 중간 다리 역할을 수행하며, 도커와 CRI 사이의 차이를 메꾸는 역할을 하게 됩니다.
image


그러나, dockershim은 영구적인 해결 방법이 되지 못했습니다.

시간이 지남에 따라, dockershim은 kubelet 자체에 많은 불필요한 복잡성을 도입하게 했고,

일부 통합은 이 dockershim에 대해 일관성이 없게 구현이 되었으며, 이로 인해 유지 관리 부담이 증가하게 됩니다.

특히나 벤더의 특정 코드(특정 제품인 Docker에 종속적인 코드)를 유지 관리하는 것은 쿠버네티스에서 추구하는 오픈 소스 철학에 부합하지도 않았구요.

따라서, 쿠버네티스는 이러한 유지 관리 부담을 줄이고자 오픈 표준을 지원하는 더 협력적인 커뮤니티로 나아가기 위해

2020년 12월 30일 쿠버네티스 개발진 중 한 명인 Wojciech Tyczynski가 dockershim 제거를 제안했고(KEP-2221),

결국 2022년 4월 쿠버네티스 v1.24에서 결국 dockershim은 제거된 채 배포됩니다.


▶︎ 쿠버네티스가 지원하는 컨테이너 런타임

쿠버네티스에서 도커가 제거되었다고 해서 문제가 되는 부분이 생기는 것은 아닙니다.

컨테이너 런타임으로 도커쉼(dockershim)을 사용해야하는 도커를 사용하지 않고,

쿠버네티스 CRI를 준수하는 다른 컨테이너 런타임을 사용하면 됩니다.

dockershim 말고도 컨테이너를 생성하고 실행하기 위해 필요한 컨테이너 런타임은 많으니까요.

그렇다면 쿠버네티스 CRI와 호환되는 컨테이너 런타임에는 어떤 것들이 있을까요?

쿠버네티스 클러스터 환경을 구축해보셨다면 이쯤에서 어떤 CRI가 가장 많이 쓰이는지 눈치채셨을 겁니다.

현재 **가장 많이 사용되는 컨테이너 런타임으로는 도커에서 분리된 containerD(컨테이너디)**가 있습니다.

사실 containerD는 도커를 컨테이너 런타임으로 사용할 때 내부적으로 사용되는 컨테이너 런타임 기술로,

이러한 기술을 도커에서 빼내어 containerd만 따로 사용하는 것이죠.

이러한 구조를 가지게 된다면 쿠버네티스와 컨테이너 간에 따로 도커쉼(dockershim)과 같은 중간 다리 역할도 필요가 없게됩니다.

dockershim에서 containerd로 넘어가게된 로직을 그림으로 표현하면 아래와 같습니다.
image
(kubernetes docs)


▶︎ 도커는 찬밥 신세?

그렇다면 도커는 이제 쿠버네티스에서 완전히 쓸모없어지게 된걸까요?

도커가 쿠버네티스에서 컨테이너 런타임으로 더 이상 사용되지 않는 것일 뿐,

도커는 개발 도구로도 여전히 사용 가능합니다.

쿠버네티스 런타임에서 도커를 제거하더라도 도커에서 만든 컨테이너 이미지를 등록하고 실행하는 것은 여전히 가능합니다.

도커가 생성하는 이미지는 여전히 표준이며, 이는 도커에만 특정된 이미지가 아닌 **OCI(Open Container Initiative)**이기 때문입니다.

즉, 도커가 생성한 이미지는 도커 뿐만 아니라 OCI 표준을 준수하는 그 어떤 컨테이너 런타임에서도 실행할 수 있습니다.

조금 주제와 벗어난 이야기지만 도커에서 만든 이미지를 다른 컨테이너 도구(podman 등)에서도 문제없이 실행 가능합니다.

예를 들어, YAML 파일을 통해 파드를 배포하는 간단한 경우를 생각해봅시다.

{% include codeHeader.html name="pod.yaml" %}

apiVersion: v1
kind: Pod
metadata:
  name: testPod
  labels:
    app: testapp
spec:
  containers:
    - name: testcontainer
      image: nginx:latest # 도커로 생성된 도커 이미지 파일

여기서 image 필드에 지정된 nginx:latest 이미지는 도커를 통해 빌드되고 배포된 이미지 입니다.

또한 이 이미지는 컨테이너 런타임인 containerd가 컨테이너를 생성할 때 **도커 레지스트리(Docker hub)**에서 이미지를 다운로드하고 실행합니다.

기본적으로 image 필드에 이미지를 nginx와 같이 지정했을 때, 이는 docker.io/nginx와 같습니다.

레지스트리 주소가 비어있는 경우에는 기본 값으로 지정된 레지스트리(docker.io)가 사용되기 때문입니다.


▶︎ 결론

따라서 개발은 여전히 도커로 진행하며, 이를 실행하는 컨테이너 런타임만 쿠버네티스와 호환되는 컨테이너 런타임으로 변경해주면

여전히 동일한 환경으로 쿠버네티스를 문제 없이 사용할 수 있습니다.

Loading script...